Currently available traffic management schemes typically have a centralized egress queuing point from which traffic is scheduled. This architecture results in a several fundamental problems relating to cost, flexibility and performance.
In terms of cost, the scale of traffic management requirements must generally be determined ahead of time and sufficient memory and other resources must be provided in an initial deployment. A negative impact of this approach is the high “cost of entry” that can be associated with meeting demanding traffic management requirements.
Flexibility can also be lacking in conventional traffic management systems, in that traffic management systems tend to be designed to fit unique customer applications, to support a number of queuing entities, depth of memory, number of virtual output ports, etc.
As the number of unique customer applications grows, the ability to monitor and react quickly enough to traffic flow changes that are specific to a particular customer application while still ensuring Service Level Agreements (SLAs) or other service commitments can be immensely challenging. Traffic management systems that are on the market today might not adequately meet this performance challenge.
Especially for egress (customer facing traffic flow) in modern communication equipment such as routers and switches, the number of interfaces and/or the number of uniquely identifiable customer traffic flows can be much greater than the physical number of “entities” that existing traffic management systems can differentiate and react to. Although software-based backpressure mechanisms have been developed to address this problem, such mechanisms might not be fast enough to sustain reasonably high customer data rates. For example, the effectiveness of many software backpressure mechanisms degrades at DS3 rates and above.
Thus, there remains a need for improved communication traffic control techniques.